Implement rule 28-6-1, only move non-const lvalues#992
Implement rule 28-6-1, only move non-const lvalues#992MichaelRFairhurst wants to merge 6 commits intomainfrom
Conversation
|
This PR is basically done and ready to be reviewed. However, this seems like it should be part of coding-standards-cpp-baseline. It has very few findings, and the findings can be fairly serious (moving a const lvalue is definitely an alarming finding). |
There was a problem hiding this comment.
Pull request overview
This PR implements MISRA C++ 2023 rule 28-6-1, which requires that std::move only be called with non-const lvalue arguments. Calling std::move on const lvalues will not result in a move operation, and calling it on rvalues is redundant. The implementation includes a new comprehensive type resolution infrastructure that replaces the previous PossiblySpecified module with a more robust ResolvesTo system that better handles typedefs, decltypes, and CV-qualifiers. Several existing queries have been refactored to use the new type resolution modules.
- Added new query for RULE-28-6-1 with comprehensive test coverage including template instantiations
- Introduced new type resolution modules (
Resolve.qll,Specifiers.qll) and value category handling (ValueCategory.qll) - Refactored 4 existing queries to use the new type resolution infrastructure
Reviewed changes
Copilot reviewed 36 out of 37 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
rules.csv |
Added RULE-28-6-1 mapping to Preconditions5 package |
rule_packages/cpp/Preconditions5.json |
New rule package metadata for RULE-28-6-1 |
cpp/misra/test/rules/RULE-28-6-1/test.cpp |
Comprehensive test cases covering const/non-const lvalues, rvalues, and template scenarios |
cpp/misra/test/rules/RULE-28-6-1/StdMoveWithNonConstLvalue.expected |
Expected query results for 21 non-compliant std::move calls |
cpp/misra/test/rules/RULE-28-6-1/StdMoveWithNonConstLvalue.qlref |
Query reference for test execution |
cpp/misra/src/rules/RULE-28-6-1/StdMoveWithNonConstLvalue.ql |
Query implementation detecting improper std::move usage |
cpp/common/src/codingstandards/cpp/types/Resolve.qll |
New comprehensive type resolution module supporting typedef/decltype resolution and specifier handling |
cpp/common/src/codingstandards/cpp/types/Specifiers.qll |
New module for handling const/volatile specifiers |
cpp/common/src/codingstandards/cpp/types/Type.qll |
Removed deprecated PossiblySpecified module |
cpp/common/src/codingstandards/cpp/ast/ValueCategory.qll |
New module for determining expression value categories (lvalue/prvalue/xvalue) |
cpp/misra/src/rules/RULE-9-5-1/LegacyForStatementsShouldBeSimple.ql |
Refactored to use new type resolution for pointer/reference type checking |
c/misra/src/rules/RULE-22-12/NonstandardUseOfThreadingObject.ql |
Updated to use ResolvesTo for threading object type detection |
c/misra/src/rules/RULE-22-13/ThreadingObjectWithInvalidStorageDuration.ql |
Updated to use ResolvesTo for threading object type detection |
c/misra/src/rules/RULE-22-14/MutexNotInitializedBeforeUse.ql |
Updated to use ResolvesTo for mutex/condition type detection |
c/cert/src/rules/INT36-C/ConvertingAPointerToIntegerOrIntegerToPointer.ql |
Refactored to use new type resolution for int/pointer type comparisons |
cpp/common/src/codingstandards/cpp/exclusions/cpp/RuleMetadata.qll |
Added Preconditions5 package metadata integration |
cpp/common/src/codingstandards/cpp/exclusions/cpp/Preconditions5.qll |
Generated exclusion metadata for RULE-28-6-1 |
cpp/common/test/library/codingstandards/cpp/types/Resolve/test.cpp |
Library tests for type resolution with 42 test cases |
cpp/common/test/library/codingstandards/cpp/types/Resolve/ResolveTest.ql |
Test query for validating type resolution functionality |
change_notes/2025-12-03-type-resolution-tracking-changes.md |
Change notes documenting the type resolution refactoring impact |
Multiple codeql-pack.lock.yml files |
Added qtil 0.0.3 dependency across all packages |
cpp/common/src/qlpack.yml |
Added qtil 0.0.3 dependency declaration |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| /** | ||
| * A type that resolves exactly to the module's `ResolvedType` type parameter. | ||
| * | ||
| * For example, `ResolvesTo<FooType>::Type` is the set of all `FooType`s and types that resolve |
There was a problem hiding this comment.
The example text refers to ResolvesTo<FooType>::Type but the actual class name is Exactly, not Type. This should be corrected to ResolvesTo<FooType>::Exactly.
| * For example, `ResolvesTo<FooType>::Type` is the set of all `FooType`s and types that resolve | |
| * For example, `ResolvesTo<FooType>::Exactly` is the set of all `FooType`s and types that resolve |
| * A type that resolves exactly to the module's `ResolvedType` type parameter. | ||
| * | ||
| * For example, `ResolvesTo<FooType>::Type` is the set of all `FooType`s and types that resolve | ||
| * (through typedefs * and/or decltypes) to `FooType`s. This does _not_ include types that resolve |
There was a problem hiding this comment.
There's a spurious asterisk in "typedefs * and/or decltypes" that should be removed. It should read "typedefs and/or decltypes".
| * (through typedefs * and/or decltypes) to `FooType`s. This does _not_ include types that resolve | |
| * (through typedefs and/or decltypes) to `FooType`s. This does _not_ include types that resolve |
| * decltype(f2); // matches (a decltype of typedef of FooType) | ||
| * typedef FT FT2; // matches (a typedef of typedef of FooType) | ||
| * | ||
| * // Examples types that are not `ResolvesTo<FooType>::Exactly` types: |
There was a problem hiding this comment.
Grammatical error: "Examples types" should be "Example types".
| * // Examples types that are not `ResolvesTo<FooType>::Exactly` types: | |
| * // Example types that are not `ResolvesTo<FooType>::Exactly` types: |
| * decltype(f) df; // does not match (non-const) | ||
| * typedef TF = FooType; // does not match (non-const) | ||
| * | ||
| * // Example `ResolvesTo<FooType>::Const` types: |
There was a problem hiding this comment.
The example text refers to ResolvesTo<FooType>::Const but the actual class name is CvConst, not Const. This should be corrected to ResolvesTo<FooType>::CvConst.
| * // Example `ResolvesTo<FooType>::Const` types: | |
| * // Example `ResolvesTo<FooType>::CvConst` types: |
| * typedef const FooType CFT; // matches (a typedef of const FooType) | ||
| * const TF ctf; // matches (a const typedef of FooType) | ||
| * | ||
| * // Additional examples types that are not `ResolvesTo<FooType>::Const` types: |
There was a problem hiding this comment.
Grammatical error: "examples types" should be "example types".
| * // Additional examples types that are not `ResolvesTo<FooType>::Const` types: | |
| * // Additional example types that are not `ResolvesTo<FooType>::Const` types: |
| * decltype(f2); // matches (a decltype of typedef of ref to FooType) | ||
| * typedef FT FT2; // matches (a typedef of typedef of ref to FooType) | ||
| * | ||
| * // Examples types that are not `ResolvesTo<FooType>::Ref` types: |
There was a problem hiding this comment.
Grammatical error: "Examples types" should be "Example types".
| * // Examples types that are not `ResolvesTo<FooType>::Ref` types: | |
| * // Example types that are not `ResolvesTo<FooType>::Ref` types: |
| * | ||
| * // Examples types that are not `ResolvesTo<FooType>::Ref` types: | ||
| * const FooType &cf; // does not match (specified references to FooTypes) | ||
| * FooType rf = f; // does not match (non-rerefence FooTypes) |
There was a problem hiding this comment.
Spelling error: "non-rerefence" should be "non-reference".
| * FooType rf = f; // does not match (non-rerefence FooTypes) | |
| * FooType rf = f; // does not match (non-reference FooTypes) |
| std::string &&l5 = std::string{"hello"}; | ||
| const std::string &&l6 = std::string{"hello"}; | ||
|
|
||
| func(std::move(l1)); // COMPLIANT - non-const lvalue |
There was a problem hiding this comment.
I wonder why wrapping std::move calls with func(...) is needed?
There was a problem hiding this comment.
Tests in general have been both cleaned up, and expanded.
| ValueCategory getValueCategory(Expr e) { | ||
| not exists(e.getConversion()) and | ||
| result = getDirectValueCategory(e) | ||
| or | ||
| if e.getConversion() instanceof ReferenceToExpr | ||
| then result = getDirectValueCategory(e) | ||
| else result = getDirectValueCategory(e.getConversion()) | ||
| } | ||
|
|
||
| private ValueCategory getDirectValueCategory(Expr e) { | ||
| if e.isLValueCategory() | ||
| then result = LValue(e.getValueCategoryString()) | ||
| else | ||
| if e.isPRValueCategory() | ||
| then result = PRValue(e.getValueCategoryString()) | ||
| else | ||
| if e.isXValueCategory() | ||
| then result = XValue(e.getValueCategoryString()) | ||
| else none() | ||
| } |
There was a problem hiding this comment.
I have noticed that getValueCategory(expr) yields the same answer as Expr.is___ValueCategory(expr) that the argument x of f(x) is a prvalue(load) in the code below:
void f(int) {}
void g(int &) {}
template <typename T> void h(T &&) {}
typedef int &IntRef;
IntRef getRef(IntRef x) { return x; }
int main() {
/* 1. `int x` as arguments to parameter, lvalue ref */
int x = 42;
f(x); // <= HERE!
g(x);
h(x);
/* 2. `IntRef y` as arguments to parameter, lvalue ref */
IntRef y = x;
f(getRef(y));
g(getRef(y));
h(getRef(y));
return 0;
}This is because of this line here:
not exists(e.getConversion()) and
result = getDirectValueCategory(e)Surprisingly, the argument x to the call f(x) does not have a conversion. I have dived more into the issue because it does not match common sense; it turns out Expr::getConversion/0 and Expr::hasLValueToRValueConversion/0 depend on different dbscheme tables.
predicate hasLValueToRValueConversion() { expr_isload(underlyingElement(this)) }
Expr getConversion() { exprconv(underlyingElement(this), unresolveElement(result)) }(exprconv/2 is what Expr::hasConversion/0, Expr::hasImplicitConversion/0, Expr::hasExplicitConversion/0 depend on as well. hasLValueToRValueConversion is an outlier; it is the only predicate in all of cpp-all that uses expr_isload.)
The result is that the argument of f(x) is still detected as prvalue(load). All the other arguments x in the example is detected correctly as lvalue and glvalue because those have conversions. The f(x) problem may have not surfaced during development against test.cpp, because std::move's parameter is a forwarding reference, similar to h above.
So, to make this predicate more perfect (to at least cover the f(x) case above, we need an additional check on expr.hasLValueToRValueConversion:
| ValueCategory getValueCategory(Expr e) { | |
| not exists(e.getConversion()) and | |
| result = getDirectValueCategory(e) | |
| or | |
| if e.getConversion() instanceof ReferenceToExpr | |
| then result = getDirectValueCategory(e) | |
| else result = getDirectValueCategory(e.getConversion()) | |
| } | |
| private ValueCategory getDirectValueCategory(Expr e) { | |
| if e.isLValueCategory() | |
| then result = LValue(e.getValueCategoryString()) | |
| else | |
| if e.isPRValueCategory() | |
| then result = PRValue(e.getValueCategoryString()) | |
| else | |
| if e.isXValueCategory() | |
| then result = XValue(e.getValueCategoryString()) | |
| else none() | |
| } | |
| ValueCategory getValueCategory(Expr e) { | |
| not (exists(e.getConversion()) or e.hasLValueToRValueConversion()) and | |
| result = getDirectValueCategory(e) | |
| or | |
| ( | |
| if e.getConversion() instanceof ReferenceToExpr and not e.hasLValueToRValueConversion() | |
| then result = getDirectValueCategory(e) | |
| else result = getDirectValueCategory(e.getConversion()) | |
| ) | |
| or | |
| ( | |
| if e.hasLValueToRValueConversion() | |
| then result = LValue("lvalue") | |
| else result = PRValue("prvalue") | |
| ) | |
| } |
(The code is not elegant; but you get the idea.)
There was a problem hiding this comment.
The A side of the diff includes getDirectValueCategory; that's not intended.
There was a problem hiding this comment.
This should be done.
I beefed up the tests for 28-6-1, and found other issues, and I think I found the underlying cause of all of this headache (CodeQL conversions vs spec behavior).
I also added tests for ValueCategory.qll to test the cases you found!
MichaelRFairhurst
force-pushed
the
michaelrfairhurst/preconditions5-only-std-move-lvalues
branch
from
fe35192 to
45a7ecc
Compare
|
Rebased to remove dependency on #991 |
Description
Implement 28-6-1, std::move with const will not move, and std::move with a non-lvalue is redundant.
Unfortunately,
expr.getLvalueCategory()did not work out of the box, as it generates extra rvalue for load steps that are transparent to the user, so we have to navigate lvalue to rvalue conversion etc to handle properly.isLvalue()also exists, but its an incomplete syntactic match. Further, the definition of an lvalue/xvalue/etc changes across C++ versions, which that function doesn't handle. While MISRA C++ 2023 currently requires C++17, we want our queries to work for users that don't comply with that restriction, for instance, users using the next version of MISRA C++ :)Change request type
.ql,.qll,.qlsor unit tests)Rules with added or modified queries
RULE-28-6-1Release change checklist
A change note (development_handbook.md#change-notes) is required for any pull request which modifies:
If you are only adding new rule queries, a change note is not required.
Author: Is a change note required?
🚨🚨🚨
Reviewer: Confirm that format of shared queries (not the .qll file, the
.ql file that imports it) is valid by running them within VS Code.
Reviewer: Confirm that either a change note is not required or the change note is required and has been added.
Query development review checklist
For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:
Author
As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
Reviewer
As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.